home *** CD-ROM | disk | FTP | other *** search
/ Univers Interactif 3 / INTERACTIF.BIN / pc / planeten / internet / tracerou.sit / Traceroute 1.0 folder / Traceroute Man Page < prev   
Text File  |  1994-06-12  |  11KB  |  220 lines
  1. TRACEROUTE(8)         MAINTENANCE COMMANDS          TRACEROUTE(8)
  2.  
  3. NAME
  4.      traceroute - print the route packets take to network host
  5.  
  6. SYNOPSIS
  7.      traceroute [ -m max_ttl ] [ -n ] [ -p port ] [ -q nqueries ]
  8.      [  -r ] [ -s src_addr ] [ -g addr ] [ -t tos ] [ -w waittime
  9.      ] host [ packetsize ]
  10.  
  11. DESCRIPTION
  12.      The Internet is a large and complex aggregation  of  network
  13.      hardware,  connected  together  by  gateways.   Tracking the
  14.      route one's packets follow (or finding the miscreant gateway
  15.      that's  discarding  your  packets)  can  be difficult.  Tra-
  16.      ceroute utilizes the IP protocol `time to  live'  field  and
  17.      attempts  to elicit an ICMP TIME_EXCEEDED response from each
  18.      gateway along the path to some host.
  19.  
  20.      The only mandatory parameter is the destination host name or
  21.      IP  number.   The default probe datagram length is 38 bytes,
  22.      but this may be increased by specifying a  packet  size  (in
  23.      bytes) after the destination host name.
  24.  
  25.      Other options are:
  26.  
  27.      -m n Set the max time-to-live (max number of hops)  used  in
  28.           outgoing  probe  packets  to n hops.  The default is 30
  29.           hops (the same default used for TCP connections).
  30.  
  31.      -n   Print hop addresses numerically  rather  than  symboli-
  32.           cally  and  numerically (saves a nameserver address-to-
  33.           name lookup for each gateway found on the path).
  34.  
  35.      -p n Set the base UDP  port  number  used  in  probes  to  n
  36.           (default  is  33434).  Traceroute hopes that nothing is
  37.           listening on UDP ports base to base+nhops-1 at the des-
  38.           tination host (so an ICMP PORT_UNREACHABLE message will
  39.           be returned to terminate the route tracing).  If  some-
  40.           thing is listening on a port in the default range, this
  41.           option can be used to pick an unused port range.
  42.  
  43.      -r   Bypass the normal routing tables and send directly to a
  44.           host  on  an attached network.  If the host is not on a
  45.           directly-attached network, an error is returned.   This
  46.           option  can  be  used  to  ping a local host through an
  47.           interface that has no route through it (e.g., after the
  48.           interface was dropped by routed(8C)).
  49.  
  50.      -s addr Use addr as the IP address (which must be  given  as
  51.              an  IP number, not a hostname) as the source address
  52.              in outgoing probe packets.  On hosts with more  than
  53.              one IP address, this option can be used to force the
  54.              source address to be something  other  than  the  IP
  55.              address  of  the  interface the probe packet is sent
  56.              on.  If the IP address is not one of this  machine's
  57.              interface  addresses, an error is returned and noth-
  58.              ing is sent.
  59.  
  60.      -g addr Enable the  IP  LSRR  (Loose  Source  Record  Route)
  61.              option in addition to the TTL tests.  This is useful
  62.              for asking how somebody else, at  IP  address  addr,
  63.              reaches a particular target.
  64.  
  65.      -t tos  Set the type-of-service in probe packets to the fol-
  66.              lowing  value  (default  zero).  The value must be a
  67.              decimal integer in the range 0 to 255.  This  option
  68.              can  be  used  to  see if different types-of-service
  69.              result in different paths.  (If you are not  running
  70.              4.4bsd,  this  may be academic since the normal net-
  71.              work services like telnet and ftp don't let you con-
  72.              trol  the  TOS).  Not all values of TOS are legal or
  73.              meaningful - see the IP spec for definitions.   Use-
  74.              ful  values are probably `-t 16' (low delay) and `-t
  75.              8' (high throughput).
  76.  
  77.      -v   Verbose  output.   Received  ICMP  packets  other  than
  78.           TIME_EXCEEDED and UNREACHABLEs are listed.
  79.  
  80.      -w n Set the time to wait for a response to  a  probe  to  n
  81.           seconds (default 3 sec.).
  82.  
  83.      This program attempts to trace the route an IP packet  would
  84.      follow  to some internet host by launching UDP probe packets
  85.      with a small ttl (time to live) then listening for  an  ICMP
  86.      "time  exceeded"  reply from a gateway.  We start our probes
  87.      with a ttl of one and increase by one until we get  an  ICMP
  88.      "port  unreachable"  (which means we got to "host") or hit a
  89.      max (which defaults to 30 hops & can be changed with the  -m
  90.      flag).   Three probes (change with -q flag) are sent at each
  91.      ttl setting and a line is printed showing the  ttl,  address
  92.      of  the  gateway  and round trip time of each probe.  If the
  93.      probe answers come from different gateways, the  address  of
  94.      each  responding  system  will  be  printed.  If there is no
  95.      response within a 3 sec. timeout interval (changed with  the
  96.      -w flag), a "*" is printed for that probe.
  97.  
  98.      We don't want the destination host to process the UDP  probe
  99.      packets  so the destination port is set to an unlikely value
  100.      (if some clod on the destination is using that value, it can
  101.      be changed with the -p flag).
  102.  
  103.      A sample use and output might be:
  104.  
  105.           [yak 71]% traceroute nis.nsf.net.
  106.           traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
  107.            1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
  108.            2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
  109.            3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
  110.            4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
  111.            5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
  112.            6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
  113.            7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
  114.            8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
  115.            9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
  116.           10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
  117.           11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms
  118.  
  119.      Note that lines 2 & 3 are the same.  This is due to a  buggy
  120.      kernel on the 2nd hop system - lbl-csam.arpa - that forwards
  121.      packets with a zero ttl (a bug in the distributed version of
  122.      4.3BSD).
  123.  
  124.      A more interesting example is:
  125.  
  126.           [yak 72]% traceroute allspice.lcs.mit.edu.
  127.           traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
  128.            1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
  129.            2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
  130.            3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
  131.            4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
  132.            5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
  133.            6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
  134.            7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
  135.            8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
  136.            9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
  137.           10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
  138.           11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
  139.           12  * * *
  140.           13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
  141.           14  * * *
  142.           15  * * *
  143.           16  * * *
  144.           17  * * *
  145.           18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms
  146.  
  147.      Note that the gateways 12, 14, 15, 16 & 17 hops away  either
  148.      don't send ICMP "time exceeded" messages or send them with a
  149.      ttl too small to reach us.  14 - 17 are running  the  MIT  C
  150.      Gateway  code  that doesn't send "time exceeded"s.  God only
  151.      knows what's going on with 12.
  152.  
  153.      The silent gateway 12 in the above may be the  result  of  a
  154.      bug  in  the  4.[23]BSD  network code (and its derivatives):
  155.      4.x (x <= 3) sends an unreachable message using whatever ttl
  156.      remains  in the original datagram.  Since, for gateways, the
  157.      remaining  ttl  is  zero,  the  ICMP  "time   exceeded"   is
  158.      guaranteed  to not make it back to us.  The behavior of this
  159.      bug is slightly more interesting when it appears on the des-
  160.      tination system:
  161.  
  162.            1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
  163.            2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
  164.            3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
  165.            4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
  166.            5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
  167.            6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
  168.            7  * * *
  169.            8  * * *
  170.            9  * * *
  171.           10  * * *
  172.           11  * * *
  173.           12  * * *
  174.           13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !
  175.  
  176.      Notice that there are 12 "gateways" (13 is the final  desti-
  177.      nation)  and  exactly  the  last half of them are "missing".
  178.      What's really happening is that rip  (a  Sun-3  running  Sun
  179.      OS3.5)  is  using  the ttl from our arriving datagram as the
  180.      ttl in its ICMP reply.  So, the reply will time out  on  the
  181.      return  path  (with  no  notice  sent to anyone since ICMP's
  182.      aren't sent for ICMP's) until we probe with a ttl that's  at
  183.      least  twice  the  path  length.  I.e., rip is really only 7
  184.      hops away.  A reply that returns with a ttl of 1 is  a  clue
  185.      this problem exists.  Traceroute prints a "!" after the time
  186.      if the ttl is <= 1.  Since vendors ship a  lot  of  obsolete
  187.      (DEC's  Ultrix,  Sun  3.x)  or non-standard (HPUX) software,
  188.      expect to see this problem frequently and/or take care pick-
  189.      ing the target host of your probes.
  190.  
  191.      Other possible annotations after the time  are  !H,  !N,  !P
  192.      (got a host, network or protocol unreachable, respectively),
  193.      !S or !F (source route failed or fragmentation needed - nei-
  194.      ther  of  these should ever occur and the associated gateway
  195.      is busted if you see one).  If almost all the probes  result
  196.      in  some  kind  of  unreachable, traceroute will give up and
  197.      exit.
  198.  
  199.           traceroute -g 10.3.0.5 128.182.0.0
  200.  
  201.      will show the path from  the  Cambridge  Mailbridge  to  PSC
  202.      while
  203.  
  204.           traceroute -g 192.5.146.4 -g 10.3.0.5 35.0.0.0
  205.  
  206.      shows how the Cambridge Mailbrige reaches  Merit,  by  using
  207.      PSC to reach the Mailbridge.
  208.  
  209.      This program is intended for use in network  testing,  meas-
  210.      urement  and  management.   It  should be used primarily for
  211.      manual fault isolation.  Because of the load it could impose
  212.      on the network, it is unwise to use traceroute during normal
  213.      operations or from automated scripts.
  214.  
  215. AUTHOR
  216.      Implemented by Van Jacobson from a suggestion by Steve Deer-
  217.      ing.   Debugged  by  a  cast  of thousands with particularly
  218.      cogent suggestions or fixes from C. Philip Wood, Tim  Seaver
  219.      and Ken Adelman.
  220.